不了解Cookie、Session、Token？一文给你整明白
有很多小伙伴还搞不清 Cookie、Session、Token 他们的区别，今天我就带大家彻底搞懂他们。
图片来自 Pexels
Cookie
夏洛：大爷，楼上322住的是马冬梅家吧？
大爷：马都什么？
夏洛：马冬梅。
大爷：什么都没啊？
夏洛：马冬梅啊。
大爷：马什么没？
夏洛：行，大爷你先凉快着吧。
浏览器第一次访问服务端时，服务器此时肯定不知道他的身份，所以创建一个独特的身份标识数据，格式为 key=value，放入到 Set-Cookie 字段里，随着响应报文发给浏览器。
浏览器看到有 Set-Cookie 字段以后就知道这是服务器给的身份标识，于是就保存起来，下次请求时会自动将此 key=value 值放入到 Cookie 字段中发给服务端。
服务端收到请求报文后，发现 Cookie 字段中有值，就能根据此值识别用户的身份然后提供个性化的服务。
接下来我们用代码演示一下服务器是如何生成，我们自己搭建一个后台服务器，这里用的是 Spring Boot 搭建的，并且写入 SpringMVC 的代码如下：
("/testCookies")
public String cookies(HttpServletResponse response){
response.addCookie(new Cookie("testUser","xxxx"));
return "cookies";
}
这样服务器就能够根据 Cookie 中的值记住我们的信息了：
我们可以看到 Cookie 字段还是被带过去了：
在计算机打开 Chrome
在右上角，一次点击更多图标→设置
在底部，点击高级
在隐私设置和安全性下方，点击网站设置
依次点击 Cookie→查看所有 Cookie 和网站数据
如果此时你换成了 Firefox 等其他的浏览器，因为 Cookie 刚才是存储在 Chrome 里面的，所以服务器又蒙圈了，不知道你是谁，就会给 Firefox 再次贴上小纸条。
Cookie 中的参数设置
所以 Cookie 需要用一些其他的手段用来保护，防止外泄或者窃取，这些手段就是 Cookie 的属性。
所以 Cookie 才在请求头中出现，接下来我们访问 http://localhost:8005，我们发现没有 Cookie 字段了，这就是 Path 控制的路径。
②Domain
我们发现下图中左边的是有 Cookie 的字段的，但是我们访问 http://172.16.42.81:8005/testCookies，看下图的右边可以看到没有 Cookie 的字段了。这就是 Domain 控制的域名发送 Cookie。
Session
所以就出现了 Session，在一次会话中将重要信息保存在 Session 中，浏览器只记录 SessionId，一个 SessionId 对应一次会话请求。
public String testSession(HttpSession session){
session.setAttribute("testSession","this is my session");
return "testSession";
}
public String testGetSession(HttpSession session){
Object testSession = session.getAttribute("testSession");
return String.valueOf(testSession);
}
这里我们写一个新的方法来测试 Session 是如何产生的，我们在请求参数中加上 HttpSession session。
然后在浏览器中输入 http://localhost:8005/testSession 进行访问可以看到在服务器的返回头中在 Cookie 中生成了一个 SessionId。
客户端：和 Cookie 过期一致，如果没设置，默认是关了浏览器就没了，即再打开浏览器的时候初次请求头中是没有 SessionId 了。
服务端：服务端的过期是真的过期，即服务器端的 Session 存储的数据结构多久不可用了，默认是 30 分钟。
在 ManageBase 的 createSession 是用来创建 Session 的：
public Session createSession(String sessionId) {
//首先判断Session数量是不是到了最大值，最大Session数可以通过参数设置
if ((maxActiveSessions >= 0) &&
(getActiveSessions() >= maxActiveSessions)) {
rejectedSessions++;
throw new TooManyActiveSessionsException(
sm.getString("managerBase.createSession.ise"),
maxActiveSessions);
}
// 重用或者创建一个新的Session对象，请注意在Tomcat中就是StandardSession
// 它是HttpSession的具体实现类，而HttpSession是Servlet规范中定义的接口
Session session = createEmptySession();
// 初始化新Session的值
session.setNew(true);
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
// 设置Session过期时间是30分钟
session.setMaxInactiveInterval(getContext().getSessionTimeout() * 60);
String id = sessionId;
if (id == null) {
id = generateSessionId();
}
session.setId(id);// 这里会将Session添加到ConcurrentHashMap中
sessionCounter++;
//将创建时间添加到LinkedList中，并且把最先添加的时间移除
//主要还是方便清理过期Session
SessionTiming timing = new SessionTiming(session.getCreationTime(), 0);
synchronized (sessionCreationTiming) {
sessionCreationTiming.add(timing);
sessionCreationTiming.poll();
}
return session
}
可以看 StandardSession 类：
protected Map<string, session> www.jintianxuesha.com sessions = new ConcurrentHashMap<>();
Token
而 Token 是在服务端将用户信息经过 Base64Url 编码过后传给客户端，每次用户请求的时候都会带上这一段信息，因此服务端拿到此信息进行解密后就知道此用户是谁了，这个方法叫做 JWT(Json Web Token)。
Token 的优点：
简洁：可以通过 URL，POST 参数或者是在 HTTP 头参数发送，因为数据量小，传输速度也很快。
自包含：由于串包含了用户所需要的信息，避免了多次查询数据库。
因为 Token 是以 Json 的形式保存在客户端的，所以 JWT 是跨语言的。
不需要在服务端保存会话信息，特别适用于分布式微服务。
JWT 的结构
实际的 JWT 大概长下面的这样，它是一个很长的字符串，中间用.分割成三部分。
①Header
Header 是一个 Json 对象，描述 JWT 的元数据，通常是下面这样子的：
{
"alg": "HS256",
"typ": "JWT"
}
alg 属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）。
type 属性表示这个令牌（Token）的类型（type），JWT 令牌统一写为 JWT。最后，将上面的 Json 对象使用 Base64URL 算法转成字符串。
②Payload
iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号
当然除了官方提供的这几个字段我们也能够自己定义私有字段，下面就是一个例子：
{
"name": "xiaoMing",
"age": 14
}
③Signature
Java 中如何使用 Token
上面我们介绍了关于 JWT 的一些概念，接下来如何使用呢？首先在项目中引入 Jar 包：
compile('io.jsonwebtoken:jjwt:0.9.0')
然后编码如下：
// 签名算法 ，将对token进行签名
SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
// 通过秘钥签名JWT
byte[] apiKeySecretBytes = DatatypeConverter.parseBase64Binary("SECRET");
Key signingKey = new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());
Map<String,Object> claimsMap = new HashMap<>();
claimsMap.put("name","xiaoMing");
claimsMap.put("age",14);
JwtBuilder builderWithSercet = Jwts.builder()
.setSubject("subject")
.setIssuer("issuer")
.addClaims(claimsMap)
.signWith(signatureAlgorithm, signingKey);
System.out.printf(builderWithSercet.compact());
发现输出的 Token 如下：
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzdWJqZWN0IiwiaXNzIjoiaXNzdWVyIiwibmFtZSI6InhpYW9NaW5nIiwiYWdlIjoxNH0.3KOWQ-oYvBSzslW5vgB1D-JpCwS-HkWGyWdXCP5l3Ko
此时在网上随便找个 Base64 解码的网站就能将信息解码出来：
总结
Cookie 是存储在客户端的。
Session 是存储在服务端的，可以理解为一个状态列表。拥有一个唯一会话标识 SessionId。可以根据 SessionId 在服务端查询到存储的信息。
Session 会引发一个问题，即后端多台机器时 Session 共享的问题，解决方案可以使用 Spring 提供的框架。
Token 类似一个令牌，无状态的，服务端所需的信息被 Base64 编码后放到 Token 中，服务器可以直接解码出其中的数据。
GitHub 代码地址：
https://github.com/modouxiansheng/Doraemon
作者：不学无数的程序员
编辑：陶家龙、孙淑娟
出处：https://juejin.im/post/5de4c3c76fb9a071b86cc482
精彩文章推荐：